Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9703/000025_owner-urn-ietf _Wed Mar 12 12:00:19 1997.msg

Internet Message Format | 1997-04-01 | 7KB

Received: (from daemon@localhost)
    by services.bunyip.com (8.8.5/8.8.5) id MAA01875
    for urn-ietf-out; Wed, 12 Mar 1997 12:00:19 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
    by services.bunyip.com (8.8.5/8.8.5) with SMTP id MAA01870
    for <[e-mail]>; Wed, 12 Mar 1997 12:00:16 -0500 (EST)
Received: from mailhub.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA22579  (mail destined for [e-mail]); Wed, 12 Mar 97 12:00:10 -0500
Received: from ferao.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Wed, 12 Mar 1997 16:22:37 +0000
Received: from phao.jungle.bt.co.uk by ferao.jungle.bt.co.uk (Jungle-SMTP-01) ID AA23495; Wed, 12 Mar 1997 16:18:00 GMT
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 12 Mar 1997 16:25:07 +0000
To: [e-mail] (Leslie Daigle)
From: Bob Briscoe <[e-mail]>
Subject: Re: [URN] URNs grandfathering certain Object or Interface References
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
Reply-To: Bob Briscoe <[e-mail]>
Errors-To: [e-mail]

At 14:57 11/03/97 -0500, Leslie Daigle wrote:
>        .(most relevant here) what _is_ a sufficiently powerful
>         and yet generally-implementable method for specifying
>         transformations? (regexps are already dangerously
>         complex, and yet there are clearly things they cannot do).
>

I would suggest the reference in the CORBA spec I cited would be worth
reading for the thinking on context relative naming from the OMG's members.
There is years of academic thought and history behind it. CORBA naming
interoperability between very different ORB domains is targeting the same
problem as URN.

See CORBA 2.0, Universal Network Objects, PTC/96-08-04, Object Management
Group, Inc. July 1996 <URL:http://www.omg.org/corba/corbiiop.htm> [Section
10.5 & 10.6]

>The key thing to remember with the proposed URN resolution _framework_
>is that the first step in resolution is to determine the authority
>that _can_  assert machine, port, protocol for a particular URN.  I.e.,
>this is step one in distributing the problem.  Step two is to perform
>some kind of lookup at/of that authority to get that information.  The NAPTR
>proposal uses the same basic DNS lookup algorithms for both of these
steps, so
>they start to look the same.  BUT, the key thing in finding a mapping from
>UUIDs and IORs would be to determine how to find the authority for a
particular
>one, and then run some kind of local process there  to interpret the
namespace-
>specific stuff (HEX code, here).
>
>So, bringing either of these namespaces into URN-land may not just be a
question
>of throwing "URN:IOR:" or "URN:UUID:" at the beginning of the strings.  It
>may be the case that the process of developing these as URN namespaces will
>include attaching some reference to the authority that will be responsible
>for performing the analysis of the HEX representation.
>
>For example,
>
>> clsid:EFF6744C-7143-11cf-A51B-080036F12502
>could become
>  URN:clsid:<naming authority ID>:EFF6744C-7143-11cf-A51B-080036F12502
>or even
>  URN:clsid:EFF6744C-7143-11cf-A51B-080036F12502:<naming authority ID>
>
>The first step in resolving this URN is to identify that it is a clsid
>namespace URN -- this indicates how to go about finding the naming
>authority ID, which can be textually extracted from either of the above.

Duplicating the <naming authority ID> that is already embedded in the hex
would be ANATHEMA to the reliability and security of the processes for
publishing these names, not to mention performance which is why these
things are stringified to hex rather than ASCII - a big winge the OO
community has about IETF protocols is that they all appear to have been
left permanently in de-bug mode so humans can read the protocol headers (I
personally think this is a GOOD THING, but it does have performance problems).

>
>Now, if that NA-ID can be mapped onto a machine name in some regular way
>(forget the pros and cons for a moment) then even NAPTR can be used to
>look up the alias, find the current address, port and protocol to speak
>to it to _resolve_ the clsid-specific string (the HEX resolution process).
>
>If you don't want to include such a NA-ID in the URN representation of the
>clsid, you _could_ set up NAPTR to route _all_ clsid URNs to one global
>service (which could be mirrored). Note that the global service doesn't have
>to do the entire document resolution - it "only" has to apply the "hex
>decoding" algorithm to the URN.  If that can't be done quickly, then it
>would be a bottleneck no matter where it was handled.

Again, this is ANATHEMA to the designers of these systems. We have to
consider gazillions of object refs, bearing in mind that there's one for
each *object* not just each class of *object*. For instance the (fixed
size) DCE/COM name-space has been designed to be larger than the estimated
number of atoms in the universe. The CORBA namespace is gazillions of
orders of magnitude bigger than that (the number of permutations of atoms
in the universe is more relevant to the number of possible permutations of
objects, profiles and service environments).

>
>So, I don't see anything here that really breaks the paradigm of the URN
>framework acting as a "glue" that ties togethe multiple namespaces.

I think NAPTR is a neat trick for farming out the problem very early on,
however, I think we may find these object-based schemes do break the
*currently proposed* paradigm (although my understanding of how their names
are constructed is sketchy), simply because of the performance requirements
at huge scale. For instance, BT has already found experimental CORBA-based
systems to be too slow to do 0800 (free phone) look-ups within the 500msec
time budget we have between the end of dialling and ringing (before the
caller hangs up thinking there's a problem). Just object location (id
look-ups) for 4 objects out of c.1million currently takes more than this
time budget. I'm not saying an *experimental* system like NAPTR should meet
these requirements, but I am saying if the intention is to assimilate all
naming, it has to be a *requirement* to *be able to* meet the *highest*
common denominator performance target.

>It
>is a _good_ case of things to test NAPTR against -- are there people
>involved with defining the UUID and IOR namespaces that are interested in
>taking on the mapping from those spaces into a URN representation?  This
>could be a great test-case for our grandfather-a-namespace issue, if
>somebody that represents those namespaces is willing to take it on.
>

I'll refer Charlie Kindel (Microsoft) and Andrew Watson (OMG chief
architect) to the archive entries of this thread. I was going to do this
anyway once I had done an initial sanity check with the URN working group.

Bob
____________________________________________________________________________
Bob Briscoe         http://www.labs.bt.com/people/briscorj/index.htm